home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 9179 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.6 KB  |  67 lines
  1. Newsgroups: comp.lang.c
  2. Path: news.sprintlink.net!eskimo!scs
  3. From: scs@eskimo.com (Steve Summit)
  4. Subject: Re: What is &Variable (declared as: char Variable[10])?
  5. X-Nntp-Posting-Host: eskimo.com
  6. Message-ID: <DnyIGG.6xG@eskimo.com>
  7. Sender: news@eskimo.com (News User Id)
  8. Organization: schmorganization
  9. References: <4gvlnlINNppj@anvil.ugrad.cs.ubc.ca> <DnLx2r.323@eskimo.com> <TANMOY.96Mar2121557@qcd.lanl.gov>
  10. Date: Fri, 8 Mar 1996 16:14:39 GMT
  11.  
  12. In article <TANMOY.96Mar2121557@qcd.lanl.gov>, tanmoy@qcd.lanl.gov
  13. (Tanmoy Bhattacharya) writes:
  14. > In article <DnLx2r.323@eskimo.com>
  15. > scs@eskimo.com (Steve Summit) writes:
  16. > SS: A client programmer might reasonably assume that the sequence
  17. > SS:     abstract_t x; f(x);
  18. > SS: could not modify x.  In C, this assumption is of course not valid
  19. > SS: if abstract_t happens to have array type.
  20. > 
  21. > Sometime back in comp.std.c there was a post which demonstrated a
  22. > slightly different problem with abstract_t being an array type: the
  23. > following does not compile:
  24. > 
  25. > void g(abstract_t *z){}
  26. > void f(abstract_t x){g(&x);}
  27. > int main {abstract_t y={0}; f(y);}
  28.  
  29. Interesting!  Actually, it isn't hard to convince yourself that
  30. there are an infinity of such examples: since arrays are
  31. "second-class types" in C; since the compiler is continually
  32. rewriting array references and declarations for you; you're
  33. obviously never going to get very far if you try to map an
  34. abstract, "black box" type to an array type.
  35.  
  36. > (In that post the question was about va_list being such an abstract
  37. > type, but the problem is a general one.)
  38.  
  39. Yeah.  (va_list is a particularly sticky problem.)
  40.  
  41. > SS: As it happens, standard C does contain one abstract type which
  42. > SS: is, underneath, an array: jmp_buf, from <setjmp.h>.
  43.  
  44. That's an incomplete statement: there's not necessarily exactly
  45. one of these types; I think one of the peculiarities of va_list
  46. is that it's allowed to be an array type, too.
  47.  
  48. > SS: ...since setjmp must modify its
  49. > SS: argument, we are left with the peculiar requirement that jmp_buf,
  50. > SS: though seemingly abstract, must be an array type.
  51. > 
  52. > No. The standard specifies that setjmp may be a macro...  As a
  53. > macro can modify its argument, no requirement on jmp_buf actually
  54. > exists.
  55.  
  56. Well, yes and no.  Now that you mention it, it's a tiny bit unclear
  57. whether setjmp may be or must be a macro.  Section 4.6.1.1 (old ANSI
  58. numbering) calls it a macro, but section 4.6 says that it's
  59. unspecified whether it's "a macro or an identifier declared with
  60. external linkage."
  61.  
  62. jmp_buf, however, is specified (again, in sec. 4.6) as being an
  63. array type, even if not for the reason I mentioned.
  64.  
  65.                     Steve Summit
  66.                     scs@eskimo.com
  67.